[レポート] 金とPythonと聖杯と〜オペレーショナルデータモデルを設計する #dbtCoalesce
大阪オフィスの玉井です。
2022年10月17日〜21日に行われたCoalesce 2022というハイブリッド(オンライン+オフライン)カンファレンスが開催されました。主催はdbt labs社です。
本記事は、その中で発表されたMoney, Python, and the Holy Grail: Designing Operational Data Modelsというセッションについて、レポートをお届け致します。
セッション概要
登壇者
- Benn Stancil
- Chief Analyst, Mode
超概要
今、データ分析に必要なのは、AIや機械学習のような高等技術ではなく、オペレーショナルモデルである…という内容のセッションです。その「オペレーショナルモデル」についても説明がなされます。
セッションレポート
前段
Bennと申します。私はデータチームのために設計されたモダンBIツールであるMode社で働いています。
アイスブレイクじゃないですが、昨日、dbtのセマンティックレイヤーとの統合をリリースしたので、お知らせしておきます。
興味がある方は、こちらのURLへ。でも、今日はこれについて話すつもりはありません。
その代わり、お金とPythonと聖杯の話をします。
お金の話
では、お金の話をしましょう。お金の話になると、データ分析チームと同じで、公然の秘密があるんです。
データ分析チームは様々なことを測定しています。しかし、皮肉なことに、彼らが測定できないものの1つに、データサイエンティストの職務記述書のようなものがあります。このようなもの(次スライド)がたくさん出てくるのです。
Airbnb社「Airbnbのビジネスパフォーマンスを測定するためのメトリクスと定義を提供します」
Stripe社「ビジネスを測定するためのメトリクスやダッシュボードを作成します」
Lyft社「製品の健全性を評価するメトリクスを確立します」
Airtable社は…。スライドの通りです。
同じことを永遠に続けることができます。どれくらい続けられるかというと、387,000回できます。
しかしこれだけのことでありながら、データサイエンティストやデータアナリストとして、基本的にこうして行動したいとか、物事を測りたいとか、「データ分析チームとして自分たちを測る」という話になったとき、私たちはこのようなことをたくさん言っています。
これはアナリティクスエンジニアのTristan氏の言葉です。「私たちはこれまで、データチームのROIについて、非常に手探りな会話をしてきました」
具体的にどうやるか、あまり言われてきていません。間接的な話ばかりになってしまうのです。
Hex社のBarry氏はこう言っています。「基本的に、ROIを測定するのではなく、他のチームから聞いたインパクトを直接測定するようにしましょう」
私たちはデータ分析チームとして物事を測ったり、自分たちを測ったりする際に、どのようにアプローチすればいいのでしょうか。
Sean Taylor氏が指摘したように、データ分析チームを作るには信念が必要です。
データ分析チームを雇うときは、彼らが何を提供してくれるのか、実際にやってみないとわからないのです。そのため、どのように評価すればよいのかがわからないのです。そのため、このようなケースに陥ってしまうのです。この場合も、実際にデータ分析チームを採用するかどうかは、ある種の信念の問題だと言えます。
経済がこうなってくると、企業がお金の使い方に悩むような、そんな感じになってきますよね。
逆に経済がこのように見えるとき、過去9か月間、このような見出しがたくさん出てきました。
「Doom Times in Tech」とか…。なんか鬱陶しい感じですね。
こうなると、(データ分析チームは)「あなたたちはここで何をしているのか」と聞かれるようになります。
そこで、私たちはもっと直接的にお金の話をする必要があります。私たちのしていることが何なのか、上司やCEOがいるのか、あるいは私たちの誰かがCEOになるのかを明確にする必要があります。「なぜ私はこの人たちに給料を払っているのだろう?」に対する良い答えが見つかるはずです。
Pythonの話
今回はPythonについてもお話します。
これまでにも、「データ分析チームとして、本当に価値のあることは何か」という質問を受けたことがあります。この質問を受けたとき、私たちは次のような答えを返しています。
その答えの1つが、このピラミッドです。
これはMonica Rogati氏によるピラミッドで、データサイエンスチームのニーズの階層を表したものです。
一番下の基本的なものから始まり、ロギングやETL、データクリーニングなどがあります。メトリクスのようなものもあります。でも、一番上はAIやMLといったものです。ハードな技術的なものばかりです。
私たちデータ分析チームはこのピラミッドを登っていくことになるのですが、それはおそらく、一番上にあるものの方が、一番下にあるものよりも価値があるからです。
つまり、最終的に言いたいのは、私たちがやっていることで一番価値があるのは、このピラミッドの一番上にあるものなのです。
このことを、本当に粗雑でひどい略語を使って、面白いタイトルのために言うと、それはPythonのためにあるようなものです。つまり、(データ分析チームは)このような複雑なことをするのが価値(と思われている)なのです。
私たちがよく言う2つ目の答えは、「なぜ私たちはここにいるのか」というようなものです。私たちは何をするために給料をもらっているのでしょうか。
これはマッキンゼーからの引用です。データの収集、分析、展開の基本的な目的は、より良い意思決定を行うことです。
Sequoiaも基本的に同じことを言っています(戦略的な意思決定)。つまり私たちデータ分析チームは、リーダーが大きなことを決めるのを助けるためにいるのだと言っています。
ですから、データ分析チームに対する一般的な回答は、この種の決定を推進する、深い分析をする、深い調査をする、といったものです。
「製品Aを作るか、それともBを作るか?」「国際的に展開するのか?」「営業マンをもっと雇うか?」「製品ラインを閉じて、ある広告で会議を開き、聴衆にマーケティングをして会社を売り込むか?」
これらを判断するために、(顧客は)私たちにコンサルタントとしてお金を払い、企業の意思決定を支援するのです。
私はこの仕事が好きです。この仕事は説得力があります。上記のような問いに対して答えを出したいと思っています。
でも、データチームに多額の資金を費やす理由としては、それほど説得力があるわけではありません。
また、多くのCEOがこのような態度をとっていることも一因です。
意思決定をする人の多くは、データは有用と思っていますが、最終的には直感で判断する、というようなところがあります。私たちが本当に価値を見出したいのであれば、このような問題に対処しなければなりません。
「ジェフ・ベゾスはジェフ・ベゾスのやりたいことをやるんだ」というような考え方に対処しなければなりません。ですから、データ分析チームの何が価値あるのか、という問いに対する最終的な答えは、最近よく言われるようになったのですが、「データの活性化」とか「オペレーショナルアナリティクス」とか、そういうものになると思います。ちょっと曖昧な言葉ですが…。
しかし、一般的には、データを他のチームに提供したり、データを他の場所に持ち出したりすることを言っています。
このようなことを考える企業の定義によると、オペレーショナルアナリティクスとは、データウェアハウスから信頼できるアクセス性の高いデータを基に、チーム間で共有された理解を構築することを中心としたアプローチである、とのことです。「公平性原則」の観点からも、このアプローチは重要です。
Hightouch社も同じです。基本的にはデータをデータウェアハウスからソフトウェアに取り込んで、人々が意思決定できるようにすることです。なるほど、それは素晴らしいことですね。それはそれで価値があると思います。
しかし、それを実際にインパクトのあるものにするためにはどうすればいいのか、という大きな疑問があります。データを他の場所に持っていくのはいいのですが、何のために何をするのでしょうか。どうやってそこに到達するのでしょうか。
「データの有効化」という中間段階があるのですが、この有効化というのはどういうことなのでしょうか。一般的に言われるのは、よりカスタマイズされたマーケティングキャンペーンを行うことで、カスタマーサクセスのような、より積極的な活動を行うことです。しかし、データ分析チーム全体の存在を正当化しようとするならば、このような回答はあり得ません。
そのため、「ここで何をするのか」という質問を受けると、ちょっとしたジレンマに陥ります。
(スライドの)どの答えも、実はそれほど説得力がなく、役に立つとは思えないのです。
どれも素晴らしいことではあります。実験は有用です。データの活性化も有効だし、戦略的な分析も有効です。AIも有用だと聞いています。
でも、これらは必要不可欠なものではありません。いざというときのためにあるようなものでもありません。私たちはCEOに対して、なぜここに留まるのか、なぜこのツールやチームのためにこれだけのお金を払わなければならないのか、というようなことを言わなければならないのです。
どうすればいいのでしょうか。より良い答えとは何でしょうか。
聖杯の話
そのために、聖杯の話をします。
といっても、このような非常に派手な聖杯のようなものはありません。
素晴らしい技術はたくさんあります。それらは長い成熟曲線の長い線上にあるのです。そこに到達するには、長い時間がかかります。私たちは、派手なものを、素晴らしく感じてしまいます。
聖杯はもっとシンプルなものです。大工さんのためのカップ程度のものです。これは何を意味するのでしょうか。
企業にとっての聖杯は、ビジネスのシンプルなモデル、つまりビジネスのオペレーションモデルです。
具体的にどういうことかの前に、私自身の歴史を少しお話しします。
今のようなITなことをする前は、私はカーネギー国際平和基金で仕事をしていました。シンクタンクというのでしょうか。口ではいろいろ言いますが、まあ、そのような仕事です。ここでの仕事は、2009年から2012年にかけてのことです。2008年の金融危機のすぐ後です。
そこでの私の仕事は、経済で何が起こっているかについての週刊ニュースレターを書くことでした。つまり、私の仕事は、自分にはその資格がないことについてインターネット上で罵倒することです。
この仕事で多くの時間を費やしたのは、基本的に経済で起きていることを読み、「2012年にダウンサイドシナリオを生きる」という、心ときめく見出しについて話したのは何だったのか、ということを理解することです。そのために、似非学術的な経済出版物を読むのに多くの時間を費やしました。
私はここで多くの時間を過ごしました。これはIMF(国際通貨基金)のワーキングペーパーのページです。魅力的な場所です。もっと時間をかけて見てみてください。そしてこの中で、実際に何が起こっているのかを理解するように努めてください。
こういうのをよく読みました。しかし、これは有益なものではありませんでした。
役に立ったのは、たった一人の人物、ポール・クルーグマンです。
ポール・クルーグマンという人は、政治評論家のようなものだとご存じかもしれません。今はニューヨークタイムズのライターをしています。彼はいろいろな意味で極端な人です。
元々はノーベル経済学賞を受賞したことで有名です。彼は、国際貿易に関するものなどを求めていました。2008年、彼は私たちとは違って、経済について多くのことを書きました。彼は「今何が起きているのか」「どのような政策をとるべきなのか」「こういうことを考えるべきだ」というようなことをたくさん書いていました。
彼のアプローチは、経済を逆さまにしたものです。一番簡単なのは、経済学入門のようなものに戻って、基本的な経済学のモデルで何が起こっているのかを理解することでした。
彼が出版したものは、このようなものではありません。
彼が発表したのは、このブログ記事のようなもので、最初の経済学の授業で習うようなグラフが載っています。
経済がどのように機能するかという、非常に基本的なモデルです。
彼の考えでは、何が起きているかを理解するためには(経済を理解するためには)それがどのように機能するかを理解する必要があるとのことです。それは単に数字の束を見るだけの問題ではなく、それらの数字が実際にどのように互いに関連しているかを理解する問題なのです。
だから、このような表を見るだけでは十分ではありません。これらは経済指標のようなものですが、これらのものが実際にどのように互いに関連しているかを知る必要があります。このうちの1つの数値が動くと、もう1つの数値が特定の方法で新たに動くと予想される理由などを知る必要があります。
2008年〜2009年にFRBが金利を劇的に引き下げたことで、この崖っぷちに追い込まれたのです。
ここで一般的に予想されるのは、金利が下がるとインフレが進むということです。今日の世界では、金利を引き上げると、インフレ抑制となります。
このため、多くの人が、インフレの暴走を予測しました。
これはウォールストリート・ジャーナルの論説で、基本的に「ああ、大変だ、インフレが暴走する。なぜなら金利があまりにも低かったからだ」と言っています。
つまり、あなたが見ている指標(最後のグラフ)によれば、これがあなたの期待するものであり、これが正しいということです。
しかし、クルーグマンは基本モデルを使いました。彼の基本モデルはこの程度で、非常に単純なものですが、基本的には、これが起きている文脈から経済の仕組みを理解すれば、インフレになる条件は実は整っていない・金利が低いにもかかわらずインフレが起きている、と言っていたのです。
これは、経済がどのように機能しているかを理解することで、メトリクスから読み取れることを否定したようなものです。
しかし、最終的に、彼は正しかったのです。
これはリセッション後のインフレです。グレーの棒グラフはリセッション後、横ばいでした。この後、2020年のように、明らかに上昇します。
彼は経済の仕組みについて基本的な理解をしていたので、それを理解することができたのです。KPIでは理解できない、実際に起きていることのメカニズムを知る必要があるのです。
「金利がインフレにつながるのはなぜか?」「低金利であれば、xが起こり、yが起こり、zが起こり、インフレになるはずだ」というようなことです。それが分かれば、そのメカニズムが実際にあるのかどうかが分かります。KPIやメトリクスに基づくのではなく、そうやって政策を決定すべきなのです。
このようなことから、私はデータ分析チームがすべきことは、どのようにビジネスをモデル化するかということを考えることだと思います。
ポール・クルーグマンが経済をモデル化したのと同じように、KPIやメトリクスを見るだけでなく、ビジネス内部で起きていることの基本機能を説明する業務モデルは、どのように構築すればよいのでしょうか。
オペレーショナルモデルとは?
オペレーショナルモデルとは何でしょうか。それは、ビジネスの主要な特性間の数学的な関係を記述した、ビジネスの簡略化された表現です。
オペレーションという言葉があって、それをモデリングしているにもかかわらず、機械学習モデルとは何の関係もありません。dbtモデルでもありませんし、それとは何の関係もありません。オペレーショナルアプリケーションへのインプットでもありません。また、セマンティックモデルやリレーショナルモデルでもありません。
これは、データのようなものがデータウェアハウスでつながっているようなものではありません。テーブルAがテーブルBと結合キーで結合しているようなものでもありません。この上のレイヤーで、これらのメトリクスが実世界でどのように互いに関連しているのでしょうか。
FRBが(データを結合するような方法ではなく)インフレが金利とどのように関連しているのか、そして現実の世界で実際に互いに影響を与え合っていることをどう考えるのでしょうか。
Josh Wills氏の例をいくつか紹介したいと思います。
彼は数年前に「他人とうまくやる方法」という講演をしました。そこからアイデアを盗んでみようと思います。彼は、大企業が使っているような主要なビジネスの運営モデルについて説明しました。そして、彼が説明したのは、Googleでした。
Googleは実は結構単純なんです。おそらく皆さんもお分かりでしょう。Googleのビジネスが実際にどのように機能するかを定義する、非常にシンプルな方程式があるのです。Googleのビジネスを説明しようと思えば、とても簡単な手順でできます。
まず、「Googleで検索している人の数」「一人当たりの検索回数」そして「検索した人がクリックした回数」などに応じてGoogleが1回あたりいくら稼ぐか…収益が決まります。Googleのビジネス全体は、これで説明できるのです。
他にもGoogleがやっていることはたくさんあります。それらは非常に複雑なビジネスです。検索ビジネスを抽象的に見れば、これはかなり難しいと思うでしょう。
でも、こうやって分解してみると、とてもシンプルで、たった3つのステップだけなんです。ポール・クルーグマンが言っていたように、シンプルな図式なんです。この方法で得られるものは、本当に強力なものです。
1つは、もし収益が上がったり下がったりしたら、それはこのうちの1つから来るはずだ、ということです。例えば、この数字が気になる変化であれば、問題や機会を特定し、「これを動かせばいいんだ」と言うのです。
もうひとつは、これらの物事は分解可能で、別々のものであることです。
例えば、「Googleで検索する人を増やすことにフォーカスしたチーム」と、「一人当たりの検索回数を増やすことにフォーカスしたチーム」を作ることができます。広告にフォーカスして、「その人たちをいかにしてより多くのお金を払ってもらえるようにするかを考えるチーム」もあります。
このように、Googleが実際にどのようなものであるかという非常にシンプルな方程式を持つことによって、ビジネス上の問題を理解しやすくなるだけでなく、問題を分解して機会を見つけ、その成長を助けることができます。そして、この基本的に同じアイデアを他のビジネスに適用することができます。
Facebookの場合、まったく同じことができます。
Facebookには「ある日のFacebookでの【いいね!】アクティブユーザーの数」があります。エンゲージメントは「特定の日にFacebookに費やす時間」です。そして、広告の効率性、つまり「Facebookで消費される1分間にどれだけのお金を稼ぐことができるか」がわかります。
これは収益に等しく、Facebookのビジネス全体が、この非常にシンプルな方程式でとらえられます。同じことが、ここでもできます。Facebookは、グロースチーム、エンゲージメントチーム、広告チームを持っていて、これらの特定のメトリクスにだけ集中しています。
このように、この問題を分解することで、Facebookが何をしようとしているのか、非常に明確に理解することができるのです。
SaaSのようなビジネスでも同じことができます。
例えば、SlackはB2BのSaaSビジネスで、利用する人の数によって課金されます。つまり、シートベースのモデルのようなものです。そのため、Slackの場合、以下のようなものがあります。
「サインアップ数×サインアップ後のユーザー維持率×実際に有料プランにコンバージョンした人数=収益」という感じです。
さて、これをさまざまな方法で行うことができます。この方法には、エンゲージメント率やエンゲージメント率別のコンバージョン率など、さまざまな微調整が可能です。しかし、重要なのは、このビジネスがどのように機能するかを正確に記述する、かなり単純な方程式を作ることができるということです。
また、Snowflake社のようなもう少し複雑なものでも可能です。Snowflake社は、シートを売るのではなく、お客様や私たちの会社のようなものを売るので、少し複雑なのです。だから、彼らのビジネスはこうなります。
「新規リードの数×新規アカウントのコンバージョン率×そのアカウントの転換率×そのアカウントがどれだけ拡大するかという拡大率」→これが収益です。
このように、これらのビジネスは実にシンプルな方法で分解することができます。そのため、問題を解決しようとするときに、メトリクスやダッシュボードのような抽象的な見方で考えるのではなく、「ビジネスはどのように機能しているのか?」「これらの事柄は互いにどのように関連しているのか?」という観点から考えることができます。この方が、これらの問題に実際に対処する方法がはるかに簡単になります。
さらに、このモデルによって、各ステップから派生する2次、3次のモデルを作成することができます。
マーケティングファネルモデルというものがあります。基本的に人々がウェブサイトを訪れ、マーケティングコンテンツに関与し、最終的にリードに変換するまでの流れをモデル化したものです。さらに複雑なモデルを追加して、より多くのモデルを構築することができます。
余談ですが、今夜ACMEでイベントを開催します。牡蠣を食べたい方、リード作戦のモデルのようなものを間近で体験したい方、ぜひ食べに来てください(会場笑)。
リードは二次的なモデルではないのです。コンバージョン率や販売サイクルのようなものもあり、これらの個々のボックスを実際に動かしている他のすべてのモデルもあります。そして、ビジネスには他のモデルもあります。このように、すべての根底には、構築しなければならないビジネスがあるのです。
採用パイプラインのようなものも、同じようにモデル化することができます。GoogleやFacebookのような大きなボトルをベースに会社を定義し、それぞれのパーツから「これがあなたのビジネスファンクションです」と説明できるような形に分解していく方法を考えていきます。
そして、私はこれを行うための最良の方法は、George Xingの話から学ぶことができます。
彼はLyft社でデータを管理していました。この話は、Lyftから何を得られるかを説明するのに、実に説得力のある方法だと思います。
Lyftは、皆さんも想像できると思いますが、かなり複雑なビジネスです。
これはある人がLyftのビジネスの仕組みを基本的に説明しようとしたものです。非常に複雑で、多次元的な市場であり、さまざまなことが起こっています。また、さまざまな市場で成長しなければならず、さまざまな製品を持っています。
非常に利益率の低いビジネスなんです。だから、割引やプロモーションなど、いろいろな方法を考えなければなりません。これはかなり難しい問題です。例えば、Lyftのようなビジネスを考えているのなら、どうすればいいでしょうか。
「ライダーは何人募集したっけ?」「私は何人のドライバーをリクルートしようとしたか?」「ドライバーとして採用するために宣伝すべき人数はどのくらいなのか?」「そのためにどれだけのお金を費やせばいいのか」
前のスライドを見て「ああ、これだけのお金をかけないと意味がないんだ」と言うのは非常に難しいことなんです。
プロモーションを行いたい場合、Lyftは利益率の低いビジネスなので、このようなプロモーションを行うのは、何の利益もない割にとても高くつく可能性があります。そのため「どの時点でプロモーションを中止するのか」「いくら支払うのか」といったことがわからなくなります。「50ドルなのか?」「20ドルなのか?」それとも「1回だけ無料」なのか…。この前のスライドだけを見ていると、実際に把握するのは非常に難しいです。
そこで、Lyftが行ったのは、「本当にシンプルなモデルを作ろう」ということでした。それは、Excelのようなもので、基本的にビジネスの3つか4つの特性を記述し、これらがどのように関連しているかを述べました。
例えば「新しいドライバーがこれだけ増えたら、新しい乗り物がこれだけ増えるだろう」「乗り物がこれだけ増えたら、売り上げがこれだけ増えるだろう」「乗り物1台あたりの平均売り上げがこれだけ増えたら、ノブをいじることができる」というものでした。そして、このダイヤルを上げれば、反対側で何かが起こると予想される、と言うことができます。
そうすることで、ビジネス上の目標と、現場で実際に起きていることを結びつけていたのです。このデータが表現しようとしている現実の世界で起こっていることを、実際に動かしている人たちの間で起こっていることと結びつけているのです。
その結果、このモデルを使ってビジネス全体を運営することができるようになったのです。Lyftは数年にわたり 基本的にこのExcelモデルを使って、事業全体を運営していました。時とともに複雑になっていきましたが、基本的には非常にシンプルな方程式で記述されたものでした。
Lyftはこのようなモデルで、ビジネスが実際にどのように運営されているかを理解することで、全体が動いていたわけです。
さて、これを見て、「なんだか見覚えがある」と思われる方もいらっしゃるでしょう。
「財務チームが使っているオペレーショナルモデル」のように見えます。これと同じことなのでしょうか。私たちは皆、金融アナリストのようになれというのでしょうか。答えは、基本的には「イエス」です。こういうものは本当に貴重で、これなしではビジネスは成り立たないのです。
CEOはCFOをクビにしてこれを処分しろ、とは言いません。これが最後の砦になるのです。ですから、データ分析チームとして不可欠な存在になりたいのであれば、このようなものを構築して、あなたをその気にさせるのです。
金融に特化したモデルを作る必要はなく、マーケティングやセールス、プロダクトライフサイクルなどでも、同じようなモデルを作ることができます。これにはとてつもなく大きな価値があるんです。
データ分析チームの間では、CFOに報告したくないというような軽蔑の念があるようです。それはわかりますが、彼らは本当に価値のあることをやっているのです。それは見習うべきことです。私にとっては、これこそ私たちがすべきことの聖杯のようなもので、「これがビジネスの仕組みだ」という意思決定の土台になります。他のすべては、そこから派生していきます。
私たちが見るメトリクス、行おうとする意思決定、行うべき投資はすべて、ビジネスの仕組みを説明するこの種のモデルに基づいているはずなのです。
まとめ(two more things)
ということで、最後にもう2つのことをお話ししたいと思います。このようなものを作ることを考える上で、重要だと思うことです。
1つは、チームワークです。これは、データ分析チームだけでできることではありません。
採用チームの仕事を理解せずに、採用のパイプラインモデルを構築することはできません。彼らは、このモデルがどのようなものであるべきかを知っており、これが実際にどのようなもので、何を期待すべきかを知っている人々なのです。
これらは、自分たちだけで構築することはできません。彼らのところに行って、「このプロセスは、実際にどのようにモデル化すればいいと思いますか」と言わなければならないのです。
営業も同じですし…
マーケティングも同じです。
これは非常に共同作業的なものです。ますますチーム同士のコラボレーションが進んでいます。その一環として、これらの機能が何をしようとしているのかを理解する必要があります。そして、それをモデル化し、構築するための簡単な方法を提案するのが、私たちの仕事です。
2つ目はメトリクスです。今、明らかにメトリクスについて多くの議論がなされています。企業としてメトリクスについて考えるとき、データ分析チームなどを使って、どんなメトリクスを作るか、ダッシュボードに何を載せるか、などといったことを考えます。
一般的なメトリクスのリストからインスピレーションを得ようとするのは、とても魅力的です。「ビジネスを成功させるための16のKPI」とか、「SaaSのベストなメトリクス」とか、そういうベストプラクティスがよくあります。ただ、他の企業のメトリクスを追いかけるようなことは、非常に本末転倒です。
その代わりに、Googleがやっていることや、Snowflakeがやっていることを考えるべきです。基本的に、私たちが望むビジネスをモデル化し、私たちのビジネスにはこれが必要だというものを選び出し、それに見合ったメトリクスを構築すべきです。メトリクスを決めてから、それを中心にビジネスを構築するのではありません。
このように、メトリクスを決めて、それを中心にビジネスを構築するというのは、お互い傷つけ合うことよりもずっと重要なことなのです。これは義務みたいなものです。
おわりに
まず、プレゼンとして非常に面白く聴講できました(スライドや構成が面白い)。
データの表面上だけ見るのではなく、その裏側(基本的な仕組み)を知ることが重要であることを、経済学を例に説明されたのは驚きでした。私もよく「データ分析は、その背後にある業務のドメイン知識が必須である」と言っているのですが、それと本質は同じかなあと思いました。
また、ビジネスをいくつかのメトリクスに分解して方程式にする(モデル化)のも目から鱗でした。どれかのメトリクスが上がったら(下がったら)、別のどれかを上げる(下げる)アクションをとる、というのは、シンプルでわかりやすいし、データ分析をビジネス成果に活かせそうですよね。